Added `databricks_permission` resource for managing permissions for individual principals. #5161

alexott · 2025-10-29T10:15:42Z

Changes

This resource provides fine-grained control over permissions by managing a single principal's access to a single object, unlike databricks_permissions, which manages all principals' access to an object at once. This is particularly useful for:

Managing permissions for different teams independently
Token and password authorization permissions that previously required all principals in one resource
Avoiding conflicts when multiple configurations manage different principals on the same object

Caveat: Since we cannot remove an individual permission, the Delete operation is performed as Read/Put, so we need to use a lock around each object.

Tests

…ndividual principals. This resource provides fine-grained control over permissions by managing a single principal's access to a single object, unlike `databricks_permissions` which manages all principals' access to an object at once. This is particularly useful for: - Managing permissions for different teams independently - Token and password authorization permissions that previously required all principals in one resource - Avoiding conflicts when multiple configurations manage different principals on the same object

github-actions · 2025-10-29T14:57:03Z

If integration tests don't run automatically, an authorized user can run them manually by following the instructions below:

Trigger:
go/deco-tests-run/terraform

Inputs:

PR number: 5161
Commit SHA: ac8512437e45348331af3eba1dea3f520b26fe36

Checks will be approved automatically on success.

mgyucht

Got through a pass. LMK what you think!

mgyucht · 2025-10-29T13:39:29Z

docs/resources/permission.md

+
+-> This resource can only be used with a workspace-level provider!
+
+~> This resource is _authoritative_ for the specified object-principal pair. Configuring this resource will manage the permission for the specified principal only, without affecting permissions for other principals.


Maybe good to note that you can't use both databricks_permission and databricks_permissions for the same object.

mgyucht · 2025-10-29T13:41:45Z

docs/resources/permission.md

+* `group_name` - (Optional) Group name to grant permissions to. Conflicts with `user_name` and `service_principal_name`.
+* `service_principal_name` - (Optional) Application ID of the service principal. Conflicts with `user_name` and `group_name`.
+
+Exactly one of the following object identifiers must be specified:


Just curious: do you like the pattern of having a separate field for each permission type? I was thinking that it might be more scalable to split a bit from how databricks_permissions works and instead have object_type and object_id fields. That way, as new object types are added, this resource doesn't need to be updated. I think the IDs are all the same type IIUC. We should then point people to the REST API docs for the set of allowed types.

It could be easier to read in some cases, but let me try to play with it

Also, we use specific field name to validate what are supported permissions... and additional customization. So it makes sense to support only explicit fields. Plus, compatibilit with permissions resouce

mgyucht · 2025-10-29T13:43:23Z

internal/providers/pluginfw/products/permissions/object_mutex.go

+// concurrently, each doing GET -> filter -> SET, which could result in
+// lost permission updates.
+type objectMutexManager struct {
+	mutexes map[string]*sync.Mutex


Suggestion: you can use sync.Map and then don't need a separate mapLock.

mgyucht · 2025-10-29T13:44:26Z

internal/providers/pluginfw/products/permissions/object_mutex.go

+// lockObject acquires a lock for the given object ID.
+// This should be called at the start of any operation that modifies permissions.
+func lockObject(objectID string) {
+	globalObjectMutexManager.Lock(objectID)
+}
+
+// unlockObject releases the lock for the given object ID.
+// This should be called at the end of any operation that modifies permissions.
+// Use defer to ensure it's always called even if the operation panics.
+func unlockObject(objectID string) {
+	globalObjectMutexManager.Unlock(objectID)
+}


Are these used outside of tests? Do we need these?

mgyucht · 2025-10-29T13:45:35Z

internal/providers/pluginfw/products/permissions/object_mutex.go

+// Lock acquires a mutex for the given object ID.
+// Each object ID gets its own mutex to allow concurrent operations on different objects
+// while serializing operations on the same object.
+func (m *objectMutexManager) Lock(objectID string) {


Since this is just used for permissions, maybe we accept object type and object ID as parameters and synthesize an appropriate key.

mgyucht · 2025-11-04T15:24:38Z

internal/providers/pluginfw/products/permissions/resource_permission.go

+	}
+
+	// Parse the ID to get object ID and principal
+	objectID, _, err := r.parseID(id.ValueString())


This should not be necessary in update, since the object ID should be in the PermissionResourceModel

mgyucht · 2025-11-04T15:25:20Z

internal/providers/pluginfw/products/permissions/resource_permission.go

+	resp.Diagnostics.Append(resp.State.SetAttribute(ctx, path.Root("permission_level"), currentPermissionLevel)...)
+}
+
+func (r *PermissionResource) Update(ctx context.Context, req resource.UpdateRequest, resp *resource.UpdateResponse) {


Are create and update basically the same? (which makes sense because permissions are essentially a singleton) Should we deduplicate by putting the create and update implementations in a single method?

mgyucht · 2025-11-04T15:26:09Z

internal/providers/pluginfw/products/permissions/resource_permission.go

+	var id types.String
+	resp.Diagnostics.Append(req.State.GetAttribute(ctx, path.Root("id"), &id)...)
+	if resp.Diagnostics.HasError() {
+		return
+	}
+
+	w, err := r.Client.WorkspaceClient()
+	if err != nil {
+		resp.Diagnostics.AddError("Failed to get workspace client", err.Error())
+		return
+	}
+
+	// Parse the ID to get object ID and principal
+	objectID, principal, err := r.parseID(id.ValueString())
+	if err != nil {
+		resp.Diagnostics.AddError("Failed to parse resource ID", err.Error())
+		return
+	}


Ditto, we shouldn't need to parse the ID to get details about the permission, it should be in state. The only place it may not be in state is in Read (post-import).

mgyucht · 2025-11-04T15:27:47Z

internal/providers/pluginfw/products/permissions/resource_permission.go

+	// Set principal fields - use null for empty strings to avoid ImportStateVerify failures
+	if userName != "" {
+		resp.Diagnostics.Append(resp.State.SetAttribute(ctx, path.Root("user_name"), types.StringValue(userName))...)
+	} else {
+		resp.Diagnostics.Append(resp.State.SetAttribute(ctx, path.Root("user_name"), types.StringNull())...)
+	}
+
+	if groupName != "" {
+		resp.Diagnostics.Append(resp.State.SetAttribute(ctx, path.Root("group_name"), types.StringValue(groupName))...)
+	} else {
+		resp.Diagnostics.Append(resp.State.SetAttribute(ctx, path.Root("group_name"), types.StringNull())...)
+	}
+
+	if servicePrincipalName != "" {
+		resp.Diagnostics.Append(resp.State.SetAttribute(ctx, path.Root("service_principal_name"), types.StringValue(servicePrincipalName))...)
+	} else {
+		resp.Diagnostics.Append(resp.State.SetAttribute(ctx, path.Root("service_principal_name"), types.StringNull())...)
+	}
+
+	// Set permission level
+	resp.Diagnostics.Append(resp.State.SetAttribute(ctx, path.Root("permission_level"), types.StringValue(permissionLevel))...)


Should we populate an instance of PermissionResourceModel and then write the entire resource to the plan?

mgyucht · 2025-11-04T15:29:19Z

permissions/resource_permission_acc_test.go

@@ -0,0 +1,518 @@
+package permissions_test


Can you move this test to the internal/providers/pluginfw/products/permissions package?

alexott requested review from a team as code owners October 29, 2025 10:15

alexott requested review from mgyucht and removed request for a team October 29, 2025 10:15

alexott temporarily deployed to test-trigger-is October 29, 2025 10:15 — with GitHub Actions Inactive

alexott temporarily deployed to test-trigger-is October 29, 2025 10:16 — with GitHub Actions Inactive

alexott added the ai-assisted label Oct 29, 2025

alexott mentioned this pull request Oct 29, 2025

Added databricks_permission resource *DRAFT* #4609

Closed

5 tasks

alexott added 2 commits October 29, 2025 12:00

remove unneeded code

d7e9b53

Fix race condition when deleting individual permissions

d1a5c7b

alexott temporarily deployed to test-trigger-is October 29, 2025 11:14 — with GitHub Actions Inactive

alexott temporarily deployed to test-trigger-is October 29, 2025 11:15 — with GitHub Actions Inactive

implement import, better handling of missing permissions

e2edb57

alexott temporarily deployed to test-trigger-is October 29, 2025 14:14 — with GitHub Actions Inactive

alexott temporarily deployed to test-trigger-is October 29, 2025 14:15 — with GitHub Actions Inactive

more fixes for tests

ac85124

alexott temporarily deployed to test-trigger-is October 29, 2025 14:56 — with GitHub Actions Inactive

alexott temporarily deployed to test-trigger-is October 29, 2025 14:57 — with GitHub Actions Inactive

mgyucht reviewed Nov 4, 2025

View reviewed changes


		-> This resource can only be used with a workspace-level provider!

		~> This resource is _authoritative_ for the specified object-principal pair. Configuring this resource will manage the permission for the specified principal only, without affecting permissions for other principals.

Added databricks_permission resource for managing permissions for individual principals. #5161

Are you sure you want to change the base?

Added databricks_permission resource for managing permissions for individual principals. #5161

Uh oh!

Conversation

alexott commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Tests

Uh oh!

github-actions bot commented Oct 29, 2025

Uh oh!

mgyucht left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexott Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Added `databricks_permission` resource for managing permissions for individual principals. #5161

Added `databricks_permission` resource for managing permissions for individual principals. #5161

alexott commented Oct 29, 2025 •

edited

Loading

alexott Nov 4, 2025 •

edited

Loading